Modern integrated circuits may have millions of transistors or “gates” created on monolithic substrates of silicon. These circuits, perhaps two tenths of an inch square, are quite complex in their internal organization. This complexity makes it difficult to test whether they are functioning properly in accordance with their design, and also whether the design itself was without errors. Early testing of the design on integrated circuit simulators is quite important, since the cost of having to correct a flawed design after the integrated circuit is already being manufactured can be extremely high.
For this reason, integrated circuit designs are put through a rigorous design testing process before the circuits are manufactured. This process is called “design verification” and it is performed in software or hardware simulators that are configured to imitate the operation of the integrated circuit.
Each succeeding generation of integrated circuits poses new design verification problems. Following Moore's law, design complexity is doubling every 12-18 months, which causes design verification complexity to increase at an exponential rate. In addition, competitive pressures increasingly demand shorter time to market. The combination of these forces has caused an ever worsening “verification crisis”.
Simulation-based functional verification is by far the most popular method of functional verification today, and is widely used within the digital design industry as a method for finding defects within designs. A wide variety of products are available in the market to support simulation-based verification methodologies. However, a fundamental problem with conventional simulation-based verification approaches is that they are slow and often do not uncover all design errors due to the unavoidable shallowness of the tests and the limited time available to run simulations.
One such limitation that is of particular concern for the testing of cache memory devices is the inability to determine design errors resulting in corrupted data in cache memory locations and the effect on subsequent cache memory operations.
For example, one common cache memory test is to write data to a cache memory location, to read back the contents of the memory location, and to compare the actual results of the read with the intended results. In this test, the results that are read back should be the same as the intended result, i.e. the number that was originally written to the memory location. This test will uncover simple apparent errors in the design, but it may not identify other, deeper design errors.
Some deeper design errors that may cause corruption of data stored in cache memory locations may not appear immediately, but only after a predetermined number or sequence or type of cache memory operations.
To uncover such errors, it would be beneficial to test a cache memory device by (1) writing data to a cache memory location, (2) performing many cache memory operations that should have no effect on that written-to cache memory location, and then (3) reading back the contents of the written-to cache memory location and comparing it with the data originally stored.
It would also be beneficial to have a program that would automatically generate a variety of cache memory operations in no predetermined order, while keeping track of all cache memory write functions and cache memory contents.
It would also be desirable to have a test system that would write data to a memory location with a first function, apply several other second functions that (according to the design of the cache memory device) do not affect that memory location, and then follow up with a third function that checks the memory location to see whether the second functions erroneously changed the value of the memory location.
It would also be desirable to have a test settings file containing test parameters to select whether data verification should be performed or not.